HOTKEY.DLL TSR Type Processing in VB by Jonathan Zuck Copyright 1991 User Friendly, Inc. Greetings! HOTKEY.DLL is designed to provide hotkey support to Visual Basic as this is not directly supported in VB. You can define multiple hot keys in your application and the DLL can be used by multiple applications simultaneously. The Point: The point is that you might want to create a TSR type utility in VB that "pops up" or performs some background task given a certain "hot key." For example, let's say that you want to be able to insert the current date the the cursor location of whatever text editor you are using. This is normally impossible to accomplish in VB. Not anymore! Now you can create a ultility that has a hot key of Ctrl-D that, while as an icon, inserts today's date in whatever application you are using. Another example might be a popup calander application. Normally, the user would have to double-click on your icon, but now you can define a key that brings your application to the fore front for immediate use. I am certain, that when you think about it, you will be able to come up with much more interesting ideas, but those are just a couple. How do You Do It? Well, HOTKEY.DLL has two functions: CreateHK and KillHK. The former establishes a hotkey and the latter gets rid of them. The syntax for them is as follows: hHotKey = CreateHK (VKCode, Shift, Wnd, UserVK) where VKCode is an valid virtual key code. These are the same codes used in the KeyDown and KeyUp event handlers. The values for the different keys can be found in CONSTANT.TXT with the KEY_ prefix. Shift is the mask for the shift keys you want included in your hot key. These are the same as those used in the KeyDown and KeyUp events in the "Shift" parameter. These values can be added together for multiple shift keys. This concept is explained on page 277 of the Programmer's Guide. Wnd is the hWnd property of the Form that you want to receive "hot key events." Therefore, you would normally simply pass hWnd as this parameter. UserVK is the value you want sent to your window when your hot key comes up. This can be any value you want it to be. It is best to start with values over 144 as this is where the normal Key_Codes end. This can be *any* valid integer hHotKey is returned by the function as the "handle" to the hotkey. This is used only to "kill" the hotkey later on. This will be set to (-1) if the hot key you selected is already in use. It will return a (-2) if there are no more hot keys. You are limited to 1024 simultaneous hot keys on your desktop. Note: this does not include, any hot keys that might be defined in the Windows Macro Recorder. Those are independent of HOTKEY.DLL. Also, HOTKEY.DLL *cannot* detect if a hot key is already taken by the Windows Macro Recorder. Be careful of overlap! Once you have created as many hot keys as you want, you need to create a KeyDown event handler for that form. This event is rarely used because normally, it requires that the form have focus. This can only happen when there are no controls on the form or they are all disabled. Never fear, however, HOTKEY.DLL can easily coexist with normal KeyDown processing as long as you define UserVK codes that to not represent valid virtual key codes. Anyway, in the KeyDown handler, you will see two parameters: KeyCode and Shift. The only one of interest to us is KeyCode because the event will only be triggered if all the proper shift keys are pressed! What the KeyCode parameter will contain is the UserVK code that you specified when creating your hot key. You can then use SELECT CASE or something to process the different hot keys that you have created. All this can transpire with your app as an icon and with you app never receiving focus! When Unloading Your Form: When you are unloading your form, please call KillHK and pass the "handle" returned to you by CreatHK. Not only will this allow other applications to use those hot keys but HOTKEY.DLL does a lot of cleanup when a hot key is "killed" so that key processing is as fast as possible. When you consider that the DLL has to filter *every* keystroke, it is imperative to processes keys as fast as possible. I think it's pretty quick but I would like to hear comments from you on any performance hits you feel you are taking. I don't think the human eye will be able to notice. The Example: HOTKEY.EXE (HOTKEY.* source files) is a *very* simplistic demo of some of the features of HOTKEY.DLL. Essentially, it loads itself as an icon and then loads NotePad. You may type freely in notpad but when you use the following key combinations, funning things happen, all with NotePad never losing focus: F7 HOTKEY.EXE exits Shift-F9 The Icon toggles between two pictures Ctrl-T The Current time is inserted into Notepad Ctrl-D The Current date is inserted into Notepad Shift-Ctrl-Alt-F10 A message appears How did I do it? (For those who care...) HOTKEY was written in Turbo Pascal for Windows. I like Pascal better than C and, as a matter of priciple, I would choose to use the tool that cost me $199 and included a compiler, windows based debugger, the Whitewater Resource Toolkit all in a Windows based development environment (hey, I thought it was MS who was hot on Windows!) that allows me to create *one* source file instead of four (with all sorts of crazy link options and import libraries!). The C/SDK combo cost me close to $1,000 and it is a PITA to use. HOTKEY was not implemented as a custom control because: 1) it would have been more trouble than it was worth. 2)it probably would have required multiple keyboard hooks instead of one which would degrade performance. 3)it would only work with VB and we use lots of other similar tools and finally 4)it would have to have been done in C! Argh! Besides, Crescents is creating a low-level keyboard handler control that I will simply buy. Essentially, HOTKEY has four routines. There is an itialization routine that dims an array of record variables (you know TYPE..END TYPE) to 1024 elements. It then sets some global variables. Finally, it makes a call out to SetWindowsHook, telling it to trap all keys and to filter them through my keyboard handler: KBProc CreateHK searches through the array to see if the the hot key is already taken. If not, it inserts the passed parameters into the next possible element of the record variable array and increments the count of hotkeys in the system. The long integer returned by CreateHK is actually a combination of your hWnd and your UserVK. This way, the hotkey is uniquely identified. KillHK moves everything, below the hot key being removed, up one element in the record variable array and decrements the total. I chose to take the extra time to do this here rather than make the search longer for every keystroke. KBProc constructs a mask using GetKeyState for the SHIFT and Ctrl keys and using lParam for the ALT key. It then scans through the record variable array looking for the same keycode and mask. If it finds it, it passes the WM_KEYDOWN message to the corresponding hWhd, passing the UserVK that you provided as the parmeter. If they key is not found, it is passed on to the next keyboard handler which is usually the application you are working in. The exit procedure, unhooks KBProc from the keyboard chain and frees up the memory taken by the record variable array. That's about it. I hope you are able to find this useful in your applications and I welcome any suggestions or comments. Jonathan Zuck User Friendly, Inc. 07-26-1991 (I just hit Ctrl-D!) ----------------end-of-author's-documentation--------------- Software Library Information: This disk copy provided as a service of Public (software) Library We are not the authors of this program, nor are we associated with the author in any way other than as a distributor of the program in accordance with the author's terms of distribution. Please direct shareware payments and specific questions about this program to the author of the program, whose name appears elsewhere in this documentation. If you have trouble getting in touch with the author, we will do whatever we can to help you with your questions. All programs have been tested and do run. To report problems, please use the form that is in the file PROBLEM.DOC on many of our disks or in other written for- mat with screen printouts, if possible. PsL cannot debug pro- programs over the telephone, though we can answer questions. Disks in the PsL are updated monthly, so if you did not get this disk directly from the PsL, you should be aware that the files in this set may no longer be the current versions. Also, if you got this disk from another vendor and are having prob- lems, be aware that some files may have become corrupted or lost by that vendor. Get a current, working disk from PsL. For a copy of the latest monthly software library newsletter and a list of the 3,000+ disks in the library, call or write Public (software) Library P.O.Box 35705 - F Houston, TX 77235-5705 Orders only: 1-800-2424-PSL MC/Visa/AmEx/Discover Outside of U.S. or in Texas or for general information, Call 1-713-524-6394 PsL also has an outstanding catalog for the Macintosh.